How do I handle the "current" of this situation?

I open a module, then run a script which displays a dialog box, which depends on data from another module(this module is opened, data is read in, then the module gets closed).
Therefore, when I get to the part where I test if the original module is not null, since the original module is no longer current, the module that I thought was current is now null.

I have tried Louie's library function fSetCurrMod(), but this does not seem to help.

Any suggestions on how to resolve this?

Thank you.
Gedinfo - Wed Feb 06 12:01:11 EST 2013

Re: How do I handle the "current" of this situation?
SystemAdmin - Wed Feb 06 12:12:12 EST 2013

Could you just use
current = m
where m is the original current module?

Greg

Re: How do I handle the "current" of this situation?
llandale - Wed Feb 06 12:19:34 EST 2013

Make this a global variable:
  • Module mHome
If the script runs from the Explorer then:
  • mHome = read(Name, false, true)
Otherwise if the script runs from that open module:
  • mHome = current

Now if the module mHome gets closed, unfortunately variable "mHome" remains non-null but effectively corrupted. So you may want do this globally:
  • string NameHomeFull = fullName(mHome)
In your callbacks wondering if mHome was closed while the dialog was open, do this:
  • module m = module(NameHomeFull)
  • if (null m) then Home was closed. Abort and Clean up mess
  • elseif(m != mHome) then Home was closed and re-opened. DANGER 'Object' et tal handles corrupted. Abort and clean up mess

fSetCurrMod is useful only for those perms that require a "current" module. Otherwise I advise you to stay away from using "current".

-Louie

Re: How do I handle the "current" of this situation?
Gedinfo - Wed Feb 06 14:17:22 EST 2013

llandale - Wed Feb 06 12:19:34 EST 2013
Make this a global variable:

  • Module mHome
If the script runs from the Explorer then:
  • mHome = read(Name, false, true)
Otherwise if the script runs from that open module:
  • mHome = current

Now if the module mHome gets closed, unfortunately variable "mHome" remains non-null but effectively corrupted. So you may want do this globally:
  • string NameHomeFull = fullName(mHome)
In your callbacks wondering if mHome was closed while the dialog was open, do this:
  • module m = module(NameHomeFull)
  • if (null m) then Home was closed. Abort and Clean up mess
  • elseif(m != mHome) then Home was closed and re-opened. DANGER 'Object' et tal handles corrupted. Abort and clean up mess

fSetCurrMod is useful only for those perms that require a "current" module. Otherwise I advise you to stay away from using "current".

-Louie

I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.
Attachments

attachment_14937938_a.dxl

Re: How do I handle the "current" of this situation?
Gedinfo - Wed Feb 06 14:18:59 EST 2013

Gedinfo - Wed Feb 06 14:17:22 EST 2013
I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.

The module that the dialog depends on is now attached.
This is an archive module.
Attachments

attachment_14937941_LinksetConfig.dma

Re: How do I handle the "current" of this situation?
llandale - Wed Feb 06 15:18:43 EST 2013

Gedinfo - Wed Feb 06 14:17:22 EST 2013
I am attaching my code and the module that gets read in that the dialog depends on will be in the second post.

TestFunction() shows module m as null, even though the original module that was opened and the script run on is still open.

I'm not going to look at your module. Are you running this script from an open module or from the Explorer?

I see ReadLinksetFile() will open that module, and will close it even if it was already open. Since that function is called via FillOldLinksetData(), that module will close when you run the script. If you are running from that module then there is no "current" module.

I'm suggesting you remember which module you are dealing with using a "Module" handle at the program level; not inside some function.

-Louie

Re: How do I handle the "current" of this situation?
Gedinfo - Wed Feb 06 16:27:56 EST 2013

llandale - Wed Feb 06 15:18:43 EST 2013
I'm not going to look at your module. Are you running this script from an open module or from the Explorer?

I see ReadLinksetFile() will open that module, and will close it even if it was already open. Since that function is called via FillOldLinksetData(), that module will close when you run the script. If you are running from that module then there is no "current" module.

I'm suggesting you remember which module you are dealing with using a "Module" handle at the program level; not inside some function.

-Louie

This is run on an open module, not from the explorer.

I open up module A, then open up module B to read in the configuration data that the dialog requires, then close module B, to hopefully have module A available for the rest of the script.

I do not understand your comment of
"will open that module, and will close it even if it was already open".

The close only happens when a valid read occurs on module B.

Not sure what you mean by program level. Does this mean that Module A should be a global?

Re: How do I handle the "current" of this situation?
llandale - Thu Feb 07 13:08:31 EST 2013

Gedinfo - Wed Feb 06 16:27:56 EST 2013
This is run on an open module, not from the explorer.

I open up module A, then open up module B to read in the configuration data that the dialog requires, then close module B, to hopefully have module A available for the rest of the script.

I do not understand your comment of
"will open that module, and will close it even if it was already open".

The close only happens when a valid read occurs on module B.

Not sure what you mean by program level. Does this mean that Module A should be a global?

Sorry if I use the wrong word; I mean variables declared as "global" to the program. I see you have
  • Module mInit
declared globally and should be used for this purpose
  • Module mInit = current()
  • if ( null mInit){warningBox("run from open module"); halt}
Function TestFunction() would then NOT declare "Module m" but would use "mInit"; although as I said checking for null is inadequate.

-Louie

Scripts that run from the explorer could have this instead:
  • if (!null mInit){warningBox("Do not run from open module"); halt}

I've changed nomenclature for this module over the years, "Current", "Initial", "Original", but now is the "Home" module.